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Description 

Background 

[0001] This invention relates generally to secured sys- 
tems and more particularly to a method and apparatus 
for enabling a user to authenticate a system prior to pro- 
viding any user privileged information to the system. 
[0002] In any secured system, one of the issues that 
is of utmost concern is that of party authentication. That 
is, how do the parties know that the other party is who or 
what they claim to be? With the proliferation of electronic 
commerce in recent years, this issue has been brought 
to the forefront. In response to this problem, a myriad of 
possible solutions have been devised. 
[0003] One possible solution involves the use of a per- 
sonal identification number (PIN). In a simple PIN-based 
system, whenever a user conducts a transaction with a 
host system, such as an automatic teller machine (ATM), 
th e use r provides to the h ost system som e p hysical to ke n , 
such as an ATM card, which identifies the user to the 
host. This token typically contains some specific infor- 
mation pertaining to the user, such as the user's name, 
the user's account number, the type of the account, etc. 
In addition to the token, the user also provides to the host 
(i n res p o n se to a p ro m pt) a sec ret P I N t h at was p re vi o u s ly 
established between the user and the entity controlling 
the host (such as a bank). Based on the information 
stored on the token and the PIN provided by the user, 
the host determines whether it is transacting with an au- 
thorized user. Presumably, only the user or people au- 
thorized by the user will have knowledge of the PIN, so 
that if the correct PIN is provided to the host, the host is 
reasonably assured that it is transacting with a proper 
user. In this manner, the host authenticates the user. 
[0004] An alternative and more sophisticated solution 
involves the use of an active token. An active token, also 
referred to herein as a client, is different from the token 
mentioned above in that it has its own processing capa- 
bility. Because it has its own processing capability, the 
client can interact with the host in a more sophisticated 
mannerthataddsan extra layer of security to the system. 
In the present context, a client can be anything having 
processing capability, including but not limited to a smart 
card and a personal computer. 

[0005] In a client- host system, a typical transaction 
takes place in the following manner. First, the user initi- 
ates interaction between the client and the host. This may 
be done, for example, by inserting a smart card into a 
host system. Thereafter, it is up to the client and the host 
to authenticate each other. This is typically achieved by 
way of a two way challenge and response protocol, 
whereby the client sends a challenge to the host and 
receives a response, and the host sends a challenge to 
the client and receives a response. Further interaction 
between the two components will take place only if both 
entities receive appropriate responses to their respective 
challenges, thereby authenticating each other. Thereaf- 



ter, the host authenticates the user by prompting the user 
for a PIN. Only if the PIN entered by the user is correct 
will the host allow a transaction to take place. In this man- 
ner, all parties involved in the transaction (host, active 

5 token, and user) are authenticated. 

[0006] In addition to the authentication schemes just 
described, other schemes are currently known and avail- 
able which modify/enhance the basic authentication ca- 
pabilities. For the most part, most of these schemes are 

10 in the same vein as the schemes described above. 
[0007] An observation that can be made about the cur- 
rently available solutions is that they are primarily fo- 
cused upon two specific aspects of the authentication 
problem: (1 ) enabling the host system to authenticate the 

15 user; and (2) enabling the client and host to authenticate 
each other. In these areas, the current solutions are ad- 
equate for the most part. However, one aspect that is 
sorely missing from all of the currently available solutions 
is the ability for the user to authenticate the host system. 

20 Notice in the above schemes that the user enters his PIN 
in response to a prompt from the host. At the time that 
the user enters the PIN, the user has no assurance that 
the host is authentic. For all the user knows, he could be 
entering his PIN into a fraudulent host. Currently, the user 

25 has to assume ortake on faith that the host is an authentic 
host. Unfortunately, this faith is sometimes misplaced, 
causing the user to enter his PIN into a fraudulent host, 
thereby allowing the PIN to be stolen. 
[0008] One arrangement that has been used to steal 

30 a PIN from a user is the following. A perpetrator builds a 
fake host and places it in a likely location, such as near 
a bank or a grocery store. The fake host looks and acts 
in all superficial respects like an authentic host. When a 
user inserts his token (either active or inactive) into the 

35 fake host, the host performs one of two actions: (1) if 
possible, it reads the token to extract therefrom the iden- 
tification information pertaining to the user; or (2) itsimply 
accepts the token. Then, the fake host prompts the user 
for his PIN. Once the user enters his PIN, the fake host 

40 has accomplished its mission, which is to steal the user's 
PIN. An important point to note here is that the purpose 
of the fake host is steal the PIN, not to perform an on- 
the-spot transaction. Because the host is not trying to 
conduct a transaction, it does not need to interact with 

45 the token at all. As a result, the host authentication ca- 
pability offered by active tokens is rendered useless. The 
above arrangement can be used to steal PIN's in both 
PIN based and client-host systems. 
[0009] Once the PIN has been stolen, several scenar- 
io jos can arise. First, the fake host can simply retain the 
token. At some later time, the perpetrator can retrieve 
the token from the fake host and use it, along with the 
PIN, to conduct a variety of transactions at the user's 
expense. Alternatively, if the fake host is able to extract 

55 user identification information from the token, the fake 
host can return the token to the user with a message that 
a transaction cannot be conducted at this time. Armed 
with the identification information and the PIN, the per- 
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petrator can still perform a wide variety of transactions, 
even in the absence of the physical token. The advantage 
to the perpetrator of returning the token to the user is that 
the user most likely will not even suspect that his PIN 
has been stolen. If this is the case, the perpetrator will 
have a fairly long period of time (probably until the user's 
next statement) during which to conduct fraudulent trans- 
actions. As an additional possibility, once the PIN has 
been ascertained, the user could be assaulted and 
robbed of the physical token. In any of these scenarios, 
the user will suffer some loss. At best, it will be some 
measure of inconvenience. At worst, it could be signifi- 
cant financial and/or physical loss. 
[001 0] As the above discussion shows, the inability of 
a user to authenticate a host system can lead to great 
pitfalls for the user. The current authentication schemes 
do not provide an adequate solution to this problem. 
[001 1 ] Document WO 99/1 2308 discloses a system for 
performing regulated transactions with a network that is 
commonly accessible by a plurality of communication ter- 
minals. 

Summary of the Invention 

[0012] There is provided a method implemented by a 
client for enabling a user to authenticate a host as set 
out in claim 1 and a client for interacting with a host as 
set out in claim 4. There is also provided a method im- 
plemented by a host for enabling a user to authenticate 
a host as set out in claim 6 and a host which enables a 
user to authenticate the host as set out in claim 8. 
[0013] To overcome the shortcomings of the prior art, 
the present invention provides a mechanism for enabling 
a user to authenticate a system. This authentication is 
performed prior to the user entering any user-privileged 
information into the system, so that theft of user-privi- 
leged information by a fraudulent system is prevented. 
As used herein, the term user-privileged information re- 
fers broadly to any information that is used by a system 
to authenticate a user, including but not limited to a PIN 
or an encryption key. 

[0014] The present invention may be implemented in 
any type of system, including a host-based system and 
a client-host system. In a host-based system, the user 
initiates interaction with a host by providing some user 
identification information to the host. This information 
may include the name of the user, an account number, 
etc., but does not include any user-privileged information. 
In response, the host uses the user identification infor- 
mation to retrieve a unique message associated with the 
user. In one embodiment, this unique message is a secret 
message that was previously established between the 
user and the host. The message may be a text message, 
a sound, a graphical display, or anything that is distinc- 
tive. Once retrieved, the unique message is sent by the 
host to the user along with a prompt for some user-priv- 
ileged information. 

[0015] Only if the message sent by the host is the same 



as that expected by the user will the user provide the 
requested user-privileged information. Presumably, only 
an authentic host will know or have access to the unique 
message; thus fake host systems will not be able to send 

5 the proper message. If the proper message is not sent 
to the user, the user will not provide the user-privileged 
information to the host. In this manner, a user is allowed 
to authenticate a host, thereby preventing theft of user- 
privileged information by a fraudulent host. 

10 [0016] With some modification, this same result can 
be achieved in a client-host system. Specifically, when 
a user initiates interaction between a client and a host, 
the client performs an authentication check on the host. 
This authentication check can be performed using any 

15 known authentication technique, including but not limited 
to a challenge/response protocol. If the client determines 
that the host is an authentic host, then the client sends 
a unique message signifying to the user that the host is 
authentic. In one embodiment, this message is stored on 

20 the client and is a secret message previously established 
between the user and the client. The unique message 
may be a text message, a sound, a graphical display, or 
any informaton that is distinctive. Note that in a client- 
host system, it is the client that sends the unique mes- 

25 sage. When a user receives the unique message, the 
user is assured that: (1 ) the client has interacted with the 
host; and (2) the host is an authentic host. Thus, if the 
host thereafter prompts the userforsome user-privileged 
information, the user can rest assured that the host is an 

30 authentic host and that the user-privileged information 
can be entered safely. In this manner, the present inven- 
tion enables a user to authenticate a host, thereby pre- 
venting a fraudulent host from obtaining user-privileged 
information from a user. 

35 

Brief Description of the Drawings 
[001 7] 

40 Fig. 1 is block diagram of a client-host system in 
which the present invention may be implemented. 
Fig. 2 is a flow diagram illustrating the client-host 
methodology of the present invention. 
Fig. 3 is a block diagram of a host-based system in 

45 which the present invention may be implemented. 

Fig. 4 is a flow diagram illustrating the host-based 
methodology of the present invention. 
Fig. 5 is a block diagram of a general system in which 
the present invention may be implemented. 

50 

Detailed Description of the Embodiment(s) 

[0018] With reference to Fig. 1 , there is shown a sys- 
tem 100 in which the present invention may be imple- 
55 mented, wherein the system 100 comprises a host 1 12 
and a client 1 1 0 for interacting with the host 1 1 2. As used 
herein, the term client refers broadly to any system, ap- 
paratus, or machine having its own logic processing ca- 
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pability. In the system of Fig. 1, the general premise is 
that it is not known whether the host 1 12 is an authentic 
host. If the host 1 1 2 is a fake host, it could take on any 
one of a number of different configurations. Since the 
configuration of the host 1 12 cannot be predicted, and 
since it is for the most part irrelevant, the host 1 1 2 in Fig. 
1 is represented simply as an empty box. 
[001 9] In system 1 00, it is the client 1 1 0 that is primarily 
responsible for carrying out the methodology of the 
present invention. The client 1 1 0 comprises a main bus 
120 and a plurality of components coupled to the main 
bus 120, including a processor 122 and a storage 124. 
The storage 1 24, which may take the form of any storage 
medium including but not limited to magnetic media, op- 
tical media, and non-volatile memory, has stored in it a 
set of authentication instructions 132, one or more sets 
of data 1 34, and one or more unique messages 1 36. The 
authentication instructions 132 are executed by the proc- 
essor 1 22 to carry out the authentication methodology of 
the present invention. The data 134, which may contain 
such information as encryption keys and the like, is used 
by the processor 122 in the course of executing the au- 
thentication instructions 132, and the unique messages 
136, as discussed further below, are used by the proc- 
essor 122 to signify to the user that the client 1 10 has 
interacted with the host 1 12, and that the host is an au- 
thentic host. In one embodiment, the unique messages 
are secret messages that are provided to the client 1 10 
by the user prior to the client 1 10 interacting with the host 
1 12. The unique messages 136 may take any form, in- 
cluding but not limited to that of a text message, an audio 
message or sound, or a graphical display of some kind. 
For example, the message could be a special text phrase 
("Howarethe kids?"), aportion of the user's favorite song, 
a special icon, or a picture of something meaningful to 
the user. For purposes of the present invention, any in- 
formation that is distinctive to the userthat would normally 
not be known or guessed by a fraudulent host could be 
used as the unique message(s). 

[0020] The client further comprises a working memory 
1 25 and an interface port 1 26, both of which are coupled 
to the main bus 120. The working memory 125 is used 
by the processor 122 to facilitate instruction execution 
and data manipulation, and the interface port 1 26 is used 
by the processor 1 22 to communicate with the host 1 1 2. 
In the embodiment shown, the client 1 1 0 takes the form 
of a software driven apparatus; that is, the client 1 1 0 de- 
rives its functionality from the processor 122 executing 
a set of software or program instructions 132. While this 
is an advantageous embodiment, it should be noted that 
if so desired, the functionality of the present invention 
could be achieved using hardware logic components. 
This modification is within the scope of the present in- 
vention. 

[0021] The client 1 10 may optionally further comprise 
one or more output devices 1 28 coupled to the main bus 
1 20, and one or more user input devices 1 30 coupled to 
the main bus 120. The output devices 128 may include 



any of a number of devices designed to convey informa- 
tion to the user, including but not limited to a visual dis- 
play, an audio system (e.g. sound card and speakers), 
and a printer. The input devices 130 may include any of 

5 a number of devices designed to allow a userto provide 
input to the client 1 1 0, including but not limited to a key- 
board, a mouse, an electronic pen and pad, and a touch 
sensitive screen. Whether these devices 128, 130 are 
included as part of the client 1 10 depends upon the par- 

10 ticular client-host arrangement. More specifically, if the 
host 112 is a point-of-sale (POS) terminal or a reader 
and the client is a smart card, then it would be the host 
120 that would have the input and output devices. On 
the other hand, if the client 1 1 0 is a personal computer 

15 and the host 1 1 2 is a server coupled to the client 1 1 0 via 
a communications line (in which case, the interface port 
1 26 would be a modem), then the client 1 1 0 would most 
likely comprise the input and output devices 130, 128. 
These are only two possible client-host configurations. 

20 Other arrangements may also be implemented within the 
scope of the present invention. 

[0022] With reference to the flow diagram shown in 
Fig. 2 and the system diagram of Fig. 1 , the methodology 
of the present invention will now be described. A user 

25 begins a transaction by initiating ( 204 ) interaction be- 
tween the client 1 1 0 and the host 1 20. In a smart card- 
POS terminal type of arrangement, this is done by simply 
inserting the smart card into the POS terminal. In a client- 
server arrangement, this is done by setting up a connec- 

30 tion between the personal computer and the server using 
a modem 1 26. Once interaction is initiated, the processor 
122 executes the authentication instructions 132 stored 
in the storage 124 to carry out the methodology of the 
present invention. Under control of the instructions 132, 

35 the processor 122 interacts (208) with the host 112 to 
determine whether the host is an authentic host. This 
determination may be made using any known authenti- 
cation methodology. In one embodiment, step 208 is car- 
ried out by way of a challenge/response protocol using 

40 public/private key encryption. 

[0023] More specifically, the processor 122 takes a set 
of information (such as a random number generated by 
the processor 122) and encrypts it using a public key of 
an authentic host to derive an encrypted message. In 

45 one embodiment, this public key is pre-established be- 
tween the client and the authentic host and is stored as 
part of the data 134 in the storage 124. Once derived, 
the encrypted message is sent via the interface port 1 26 
to the host 1 1 2 as a challenge. The processor 1 22 then 

50 waits for a response. 

[0024] In response to the challenge, an authentic host 
would decrypt the message using a private key associ- 
ated with the public key used by the client. The result of 
this operation would be the original information (i.e. the 

55 random number) sent by the processor 122. It should be 
noted that only an authentic host would have this private 
key; therefore, only an authentic host would be able to 
properly decrypt the challenge message. Once the orig- 



4 



7 



EP 1 046 976 B1 



8 



inal information is derived, an authentic host would re- 
encrypt the information, this time using a client public 
key, to derive a second encrypted message. The client 
public key is a key which is pre-established between the 
client 1 1 0 and the authentic host. Once derived, the sec- 
ond encrypted message is sent to the client 1 1 0 via the 
interface port 126 as a response. 

[0025] Once the response is received, the processor 
122 tests the response by decrypting it using a private 
key associated with the client public key used by the au- 
thentic host. This private key is stored as part of the data 
134 in the storage 124 and is known only to the client 
110. If the host 1 1 2 is an authentic host, the result of this 
decryption process will be the original information sent 
by the processor 122. If the result is not the original in- 
formation sent by the processor 122, or if no response 
is received, then the processor 122 knows that the host 
1 1 2 is not an authentic host. Inthis manner, theprocessor 
1 22 and hence the client 1 1 0 determines (212) whether 
the host 1 12 is an authentic host. If host 1 12 is an au- 
thentic host, then it will most likely also try to authenticate 
the client 110. This authentication may be carried out 
using the same challenge/response methodology as that 
described above. 

[0026] If the processor 122 determines that the host 
1 1 2 is not an authentic host, then the processor 1 22 stops 
( 216 ) all further interaction with the host 1 1 2. On the other 
hand, if the processor 122 determines that the host 112 
is an authentic host, then the processor 1 22 sends ( 220 ) 
one or more of the unique messages 136 stored in the 
storage 1 24 to the user to signify to the user that: (1 ) the 
client 1 10 has interacted with the host 1 12; and (2) the 
client 1 1 0 has determined that the host 1 12 is an authen- 
tic host. In the smart card-POS configuration, the proc- 
essor 1 22 sends the unique message to the host 1 1 2 for 
output to the user using one of the output devices of the 
host 1 1 2. In the client-server configuration, the processor 
122 sends the unique message to one of its own output 
devices 128 to convey the message to the user. 
[0027] Thereafter, the user reviews (224) whatever 
message is returned as a result of the client-host inter- 
action. If the return message is one of the unique mes- 
sages expected by the user, then the user is assured that 
the client has interacted with the host 1 12 and that the 
host 112 is an authentic host; hence, the user can safely 
provide ( 236 ) to the host 112 whatever user-privileged 
information is requested by the host 1 1 2. As used herein, 
the term user-privileged information refers broadly to any 
information that is used by an authentic host to authen- 
ticate a user. User-privileged information is secret infor- 
mation known only to an authentic host, an authentic us- 
er, and authorized representatives of the authentic user, 
and can be any type of information including but not lim- 
ited to that of a PI N or an encryption key. Once the user- 
privileged information is provided to an authentic host, it 
is used by the authentic host to authenticate a user. If 
the user is authenticated, then a transaction will be al- 
lowed to take place. 



[0028] On the other hand, if the user determines ( 228 ) 
that the return message is not one of the unique mes- 
sages expected by the user, then the user knows that 
either the client did not interact properly with the host 

5 1 12, or that the host is not an authentic host. In either 
case, the user stops ( 232 ) all further interaction with the 
host 1 1 2. A point to note here is that, unlike the prior art, 
the present invention does not allow the authentication 
process between the client 110 and the host 1 12 to be 

10 bypassed or ignored. If the authentication process is not 
carried out, the processor 122 will not send any of the 
unique messages 136. If the processor 122 does not 
send any of the unique messages, then there is no way 
for the fraudulent host to know what message to send to 

15 the user. As a result, the fraudulent host will not be able 
to send the proper unique message to the user. If the 
proper message is not sent, the user will not provide to 
the host any user-privileged information. In this manner, 
the present invention prevents the theft of user-privileged 

20 information by a fraudulent host. 

[0029] As an enhancement to the present invention, it 
is possible to base the unique message that is sent by 
the processor 1 22 upon the current value of one or more 
parameters. For example, in determining which unique 

25 message to send, the processor 1 22 may check on the 
amount of the transaction that the user is trying to proc- 
ess. If the amount is less than $1 ,000, the processor 1 22 
may send the unique message "Let's conduct a transac- 
tion". On the other hand, if the amount is over $1 ,000, 

30 the processor 122 may send the unique message "Big 
Spender!". By varying the unique messages, an extra 
layer of protection is afforded in that even if a fraudulent 
host is able to replicate the unique message for the lower 
amount transactions, the higher amount transactions are 

35 still protected. The amount of the transaction is just one 
of the possible parameters that that processor 122 can 
check. Other parameters may also be checked within the 
scope of the present invention. 

[0030] Thus far, the invention has been described in 
40 terms of a client-host system. It should be noted, how- 
ever, that the invention may also be implemented in a 
host-based system. As used herein, the term host based 
system refers to any system in which the authentication 
methodology of the present invention is implemented by 
45 a host rather than a client. A block diagram of such a 
system is shown in Fig. 3. 

[0031 ] As shown in Fig. 3, the host 302 of a host based 
system 300 comprises a main bus 303 and a plurality of 
components coupled to the main bus 303, including a 

50 processor 304, a working memory 308, and a storage 
306. The storage 306 may take the form of any storage 
medium including but not limited to magnetic media, op- 
tical media, and non-volatile memory, and has stored 
within it a set of authentication instructions 310. These 

55 authentication instructions 31 0 are executed by the proc- 
essor 304 to carry out the authentication methodology of 
the present invention. The working memory 308 is used 
by the processor 304 to facilitate instruction execution 
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and data manipulation. In the embodiment shown, the 
host 302 takes the form of a software driven apparatus; 
that is, the host302 derives its functionality from the proc- 
essor 304 executing a set of software or program instruc- 
tions 310. While this is an advantageous embodiment, it 
should be noted that if so desired, the functionality of the 
present invention could be achieved using hardware logic 
components. This modification is within the scope of the 
present invention. 

[0032] The storage 306 further contains within it a user- 
privileged information database 312 and a unique mes- 
sages database 31 4. The user-privileged information da- 
tabase 312 contains information used by the processor 
304 to authenticate users. This database 312 may con- 
tain such information as PIN's and encryption keys which 
are compared with user-privileged information entered 
by users (as discussed further below) to verify that the 
users are authentic users. The unique messages data- 
base 31 4contains messages which are used by the proc- 
essor 304 to signify to users that the host 302 is an au- 
thentic host. In one embodiment, the unique messages 
are secret messages that are provided to the host 302 
by the users prior to the users interacting with the host 
302. The unique messages may take any form, including 
but not limited to that of a text message, an audio mes- 
sage or sound, or a graphical display of some kind. For 
purposes of the present invention, anything that is dis- 
tinctive to the users that would normally not be known or 
guessed by afraudulent host could be used as the unique 
messages. 

[0033] The host 304 may optionally further comprise 
a communications port 31 6, an interface port 31 8, output 
devices 320, and input devices 322, all of which are cou- 
pled to the main bus 303. Whether these components 
are included as part of the host 302 depends upon the 
specific embodiment taken by the host (discussed further 
below). The communications port 316 enables the host 
302 to communicate through a network to a back end 
330 system. The back end system 330 and the host 302 
may interact to perform any desired function. Function- 
ality between the two components may be divided freely, 
and if so desired, the functionality of the back end 330 
may be folded completely into the host 302. The com- 
munications port 316 also allows the host 302 to com- 
municate with dummy terminals 340 and clients 350. 
[0034] The interface port 318 allows the host 302 to 
communicate with tokens. These tokens, such as ATM 
cards, are utilized by users to provide user identification 
information to the host 302 and generally to interact with 
the host 302. 

[0035] The output devices 320 may include any of a 
number of devices designed to convey information to the 
users, including but not limited to a visual display, an 
audio system (e.g. sound card and speakers), and a print- 
er. The input devices 322 may include any of a number 
of devices designed to allow users to provide input to the 
client 110, including but not limited to a keyboard, a 
mouse, an electronic pen and pad, and a touch sensitive 



screen. 

[0036] According to the present invention, the host302 
may be implemented in a variety of different forms. For 
example, the host 302 may take the form of a POS ter- 

5 minal (e.g. an ATM) which interacts with inactive tokens. 
In this form, the host 302 would include the interface port 
318, the output devices 320, the input devices 322, and 
most likely the communications port 316. The host 302 
may also take the form of a mainframe computer coupled 

10 to a plurality of dummy terminals 340. In this implemen- 
tation, the host 302 would include the communications 
port 31 6 but not the interface port 31 8 or the output 320 
or input 322 devices. In addition, the host 302, may also 
take the form of a server coupled to a plurality of clients 

15 350. In this form, the host 302 would include the commu- 
nications port 316 but not the interface port 318 or the 
output 320 or input 322 devices. The host 302 may take 
on these and many other forms. In fact, the host 302 may 
be implemented as the authentication mechanism in any 

20 system to which a user needs to log in or register using 
user-privileged information. 

[0037] With reference to the flow diagram illustrated in 
Fig. 4, and the system diagram of Fig. 3, the operation 
of host 302 will now be described. Under direction of the 

25 authentication instructions 31 0 stored in the storage 306, 
the processor 304 of host 302 implements the method- 
ology of the present invention. Processor 304 begins the 
authentication process by sending ( 404 ) a prompt to the 
user for some user identification information. This infor- 

30 mation may include the user's name, the user's account 
number, the user's login, etc. but does not include any 
user-privileged information. In response, the user pro- 
vides ( 408 ) the user identification information to the host 
302. 

35 [0038] Once the user identification information is re- 
ceived, the processor 304 uses the identification infor- 
mation to retrieve (412) from the unique messages da- 
tabase 314 one or more unique messages associated 
with the identified user. The unique message is a secret 

40 message previously provided to the host 302 by the user. 
Each user has one or more customized unique messages 
associated therewith. The processor 304 thereafter 
sends ( 41 6 ) the unique message to the user, along with 
a prompt for some user-privileged information, such as 

45 a password, a PIN, or an encryption key. 

[0039] Prior to providing the user-privileged informa- 
tion requested by the host 302, the user reviews ( 420 ) 
whatever message is returned by the host in response 
to the user identification information. If the user deter- 

50 mines (424) that the return message is the unique mes- 
sage expected by the user, then the user provides ( 432 ) 
the requested user-privileged information to the host302. 
[0040] On the other hand, if the return message is not 
the unique message expected by the user, then the user 

55 knows that the host 302 is not an authentic host. In such 
a case, the user will stop ( 428 ) all further interaction with 
the host 302 and will not provide any user-privileged in- 
formation to the host. In this way, the present invention 
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enables the user to authenticate the host 302 prior to 
providing any user-privileged information. This helps to 
ensure that the user-privileged information will not be pro- 
vided to a fraudulent host. 

[0041] If the host 302 is an authentic host, and the user 
does provide a set of user-privileged information, then 
the processor 304 will verify ( 436 ) the information pro- 
vided by the user against the information stored in the 
user-privileged information database 312 stored in the 
storage 306. If the two sets of information match, then 
the host 302 knows that the user is an authentic user. In 
such a case, the host 302 will further interact with the 
user. 

[0042] Thus far, the invention has been described in 
the contexts of a client-host system and a host-based 
system. While the present invention may be advanta- 
geously implemented in such system configurations, it 
should be noted that the invention is not so limited. Rath- 
er, it may be generally applied to any type of system. 
[0043] Fig. 5 shows an overall general system 500 in 
which the present invention may be implemented, the 
system 500 comprising a user interface 502 for receiving 
input from and providing output to a user, a trusted com- 
ponent 504, and one or more other components 508. In 
system 500, thetrusted component 504 is the component 
responsible for implementing the methodology of the 
present invention. The purpose of the trusted component 
504 is to provide assurance to the user that the overall 
system is authentic. That is, if the user can determine 
that the trusted component is present in the system 500, 
then the user knows that the system is authentic. 
[0044] In system 500, the trusted component 504 may 
be implemented in anyformand in any part of the system. 
That is, it may be implemented as a software module or 
as a hardware component (e.g. a dedicated chip). It may 
be implemented as part of a client, a host, or any other 
component. For example, in the client-host implementa- 
tion (Fig. 1) described previously, the trusted component 
504 was implemented as part of the client 110. In the 
host-based system (Fig. 3) described above, the trusted 
component504was implemented as part of the host302. 
If so desired, the trusted component 504 may be imple- 
mented as part of any other component. The particular 
implementation of the trusted component 504 is not im- 
portant. What is important is that the trusted component 
504 provide to the user some assurance that the system 
500 is authentic before the user provides any user-priv- 
ileged information to the system 500. 
[0045] In achieving this purpose, the trusted compo- 
nent 504 operates as follows. It first receives, via the user 
interface 502, a set of user identification information. This 
information may include the user's name, the user's ac- 
count number, the user's login, etc., but does not include 
any user-privileged information. The trusted component 
504 then uses the identification information to retrieve 
from a storage 506 one or more unique messages asso- 
ciated with the identified user. The unique message is a 
secret messagethatonly an authentictrusted component 



504 would know. Prior to sending the unique message 
back to the user, the trusted component 504 performs 
any verifications necessary to authenticate the user in- 
terface 502 and the other components 508 of the system 

5 500. Thereafter, the trusted component 504 sends the 
unique message to the user, via the user interface 502, 
to provide assurance to the user that the system 500 is 
authentic. If the unique message is the one expected by 
the user, then the user knows that the trusted component 

10 504 is in the system 500, and hence, that the system 500 
is authentic. As a result, the user knows that he can safely 
provide user-privileged information to the system 500. 
On the other hand, if the return message is not the unique 
message expected by the user, then the user knows that 

15 the system 500 is not an authentic system. In such a 
case, the user will stop all further interaction with the sys- 
tem 500. In this manner, the present invention enables 
the user to authenticate the system 500 prior to providing 
any user-privileged information to the system 500. This 

20 in turn prevents user-privileged information from being 
provided to fraudulent systems. 

[0046] At this point, it should be noted that although 
the invention has been described with reference to spe- 
cific embodiments, it should not be construed to be so 

25 limited. Various modifications can be made by those of 
ordinary skill in the art with the benefit of this disclosure 
without departing from the spirit of the invention. Thus, 
the invention should not be limited by the specific em- 
bodiments used to illustrate it but only by the scope of 

30 the appended claims. 



Claims 

35 1. A method implemented by a client (110) for enabling 
a user to authenticate a host (1 12), comprising: 



interacting (208) with the host (1 1 2) to determine 
whether the host (112) is an authentic host 

40 (112); and 

in response to a determination that the host 
(112) is an authentic host (112), sending (220) 
a unique message that signifies to the user that 
the client (1 1 0) has interacted with the host (1 12) 

45 and thatthe host (1 1 2) is an authentic host (112), 

wherein the unique message is a secret mes- 
sage that is not known by the host (1 1 2) and that 
was previously provided to the client (110) by 
the user; 

50 

characterised in that the step of sending a unique 
message comprises: 

determining the current value of one or more 
55 parameters; 

selecting, based upon the current value of the 
one or more parameters, one of a plurality of 
unique messages; and 
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sending the selected unique message to the us- 
er to signify to the user that the client (110) has 
interacted with the host (1 12) and that the host 
(1 1 2) is an authentic host (1 1 2). 

5 

2. The method of claim 1 , wherein the unique message 
is sent to the host (1 1 2) for display by the host (1 1 2) 
to the user. 

3. The method of claim 1 , wherein interacting with the 10 
host (112) comprises: 

sending a challenge to the host (112); 
receiving from the host (112) a response to the 
challenge; and 15 
determining based upon the response whether 
the host (112) is an authentic host (112). 

4. A client (110) for interacting with a host (112), the 
client (1 1 0) enabling a user to authenticate the host 20 
(1 12), the client (1 10) comprising: 

storage for storing a unique message; 
a mechanism for interacting with the host to de- 
termine whether the host (1 12) is an authentic 25 
host; and 

a mechanism for sending, in response to a de- 
termination that the host (112) is an authentic 
host (112), the unique message to the user to 
signify to the user that the client (1 10) has inter- 30 
acted with the host (1 1 2) and that the host (1 1 2) 
is an authentic host, wherein the unique mes- 
sage is a secret message that is not known by 
the host (1 1 2) and that was previously provided 
to the client (1 10) by the user; 35 

characterised in that the storage stores a plurality 
of unique messages, and wherein the mechanism 
for sending comprises: 

40 

a mechanism for determining the current value 
of one or more parameters; 
a mechanism for selecting, based upon the cur- 
rent value of the one or more parameters, one 
of the plurality of unique messages stored in the 45 
storage; and 

a mechanism for sending the selected unique 
message to the user to signify to the user that 
the client (1 10) h as interacted with the host (1 12) 
and that the host (1 1 2) is an authentic host. 50 

5. The client (1 1 0) of claim 4, wherein the mechanism 
for interacting with the host (1 1 2) comprises: 

amechanismforsendingachallengetothe host 55 
(112); 

a mechanism for receiving from the host (1 12) 
a response to the challenge; and 



a mechanism for determining based upon the 
response whether the host (1 12) is an authentic 
host (112). 

6. A method implemented by a host (1 1 2) for enabling 
a user to verify that the host (1 12) is an authentic 
host (1 12), comprising: 

receiving a set of user identification information 
from the user; 

retrieving, based upon the user identification in- 
formation, a unique message associated with 
the user, the unique message being a secret 
message that only an authentic host (1 1 2) would 
know; and 

sending the unique message to the user to en- 
able the user to verify that the host (1 1 2) is an 
authentic host (112), wherein the unique mes- 
sage is a secret message previously provided 
to the host (112) by the user; 

characterised in that the step of sending a unique 
message comprises: 

determining the current value of one or more 
parameters; 

selecting, based upon the current value of the 
one or more parameters, one of a plurality of 
unique messages; and 

sending the selected unique message to the us- 
er to signify to the user that the client (110) has 
interacted with the host (112) and that the host 
(1 1 2) is an authentic host (1 1 2). 

7. The method of claim 6, further comprising: 

receiving a set of user-privileged information 
from the user, the user providing the user-priv- 
ileged information only afterthe user has verified 
thatthe host (1 1 2) is an authentic host (1 1 2); and 
determining, based upon the user-privileged in- 
formation, whetherthe user is an authentic user. 

8. A host (1 1 2) which enables a user to verify the au- 
thenticity of the host (1 12), comprising: 

storage for storing a unique message associat- 
ed with the user; 

a mechanism for receiving from the user a set 

of user identification information; 

a mechanism for retrieving, based upon the user 

identification information, the unique message 

associated with the user, the unique message 

being a secret message that only an authentic 

host (1 12) would know; and 

a mechanism for sending the unique message 

to the user to enable the user to verify that the 

host (112) is an authentic host (112), wherein 
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the unique message is a secret message previ- 
ously provided to the host (112) by the user; 

characterised in that the storage stores a plurality 
of unique messages, and wherein the mechanism 5 
for sending comprises: 

a mechanism for determining the current value 
of one or more parameters; 

a mechanism for selecting, based upon the cur- 10 
rent value of the one or more parameters, one 
of the plurality of unique messages stored in the 
storage; and 

a mechanism for sending the selected unique 
message to the user to signify to the user that 15 
the client (1 1 0) has interacted with the host (1 12) 
and that the host (112) is an authentic host. 

9. The host (112) of claim 8, further comprising: 

20 

a mechanism for receiving from the user a set 
of user-privileged information, the user entering 
the user-privileged information only after the us- 
er has verified that the host (1 1 2) is an authentic 
host (112); and 25 
a mechanism for determining, based upon the 
user-privileged information, whether the user is 
an authentic user. 

30 

Patentanspruche 

1 . Verfahren, das von einem Client (1 1 0) implementiert 
wird, urn einem Benutzerzu ermoglichen, einen Host 
(112) zu authentisieren, umfassend: 35 

Interagieren (208) mit dem Host (112), um zu 
bestimmen, ob der Host (112) ein authentischer 
Host (112) ist; und 

in Reaktion auf eine Feststellung, dass der Host 40 
(1 1 2) ein authentischer Host (1 1 2) ist, Senden 
(220) einer eindeutigen Nachricht, die dem Be- 
nutzer anzeigt, dass der Client (110) mit dem 
Host (112) interagiert hat und dass der Host 
(1 12) ein authentischer Host (112) ist, wobei die 45 
eindeutige Nachricht eine geheime Nachricht 
ist, die dem Host (1 1 2) nicht bekannt ist und die 
vom Benutzer dem Client (110) im Voraus zur 
Verfugung gestellt wurde; 

50 

dadurch gekennzeichnet, dass der Schritt des 
Sendens einer eindeutigen Nachricht umfasst: 

Bestimmen des aktuellen Wertes eines Para- 
meters oder mehrerer Parameter; 55 
Auswahlen einer von mehreren eindeutigen 
Nachrichten auf der Grundlage des aktuellen 
Wertes des einen Parameters oder der mehre- 



ren Parameter; und 

Senden der ausgewahlten eindeutigen Nach- 
richt an den Benutzer, um dem Benutzer anzu- 
zeigen, dass der Client (1 10) mit dem Host(1 12) 
interagiert hat und dass der Host (112) ein au- 
thentischer Host (112) ist. 

2. Verfahren nach Anspruch 1, wobei die eindeutige 
Nachricht an den Host (1 12) gesendet wird, um sie 
mittels des Hosts (112) dem Benutzer anzuzeigen. 

3. Verfahren nach Anspruch 1 , wobei das Interagieren 
mit dem Host (112) umfasst: 

Senden einer Aufforderung an den Host (1 12); 
Empfangen einer Antwort auf die Aufforderung 
vom Host (1 12); und 

Bestimmen auf der Grundlage der Antwort, ob 
der Host (1 1 2) ein authentischer Host (1 1 2) ist. 

4. Client (110) fur das Interagieren mit einem Host 
(1 12), wobei derClient(1 1 0) einem Benutzerermog- 
licht, den Host (112) zu authentisieren, wobei der 
Client (110) umfasst: 

einen Speicher zum Speichern einer eindeuti- 
gen Nachricht; 

eine Einrichtungzum Interagieren mitdem Host, 
um zu bestimmen, ob der Host (1 1 2) ein authen- 
tischer Host ist; und 

eine Einrichtung zum Senden der eindeutigen 
Nachricht an den Benutzer in Reaktion auf eine 
Feststellung, dass der Host (112) ein authenti- 
scher Host (112) ist, um den Benutzer anzuzei- 
gen, dass der Client (110) mit dem Host (1 12) 
interagiert hat und dass der Host (112) ein au- 
thentischer Host ist, wobei die eindeutige Nach- 
richt eine geheime Nachricht ist, die dem Host 
(112) nichtbekanntistundvom Benutzer im Vor- 
ausdem Client (1 1 0) zur Verfugung gestelltwur- 
de; 

dadurch gekennzeichnet, dassderSpeichermeh- 
rere eindeutige Nachrichten speichert, wobei die 
Einrichtung zum Senden umfasst: 

eine Einrichtung zum Bestimmen des aktuellen 
Wertes eines Parameters oder mehrerer Para- 
meter; 

eine Einrichtungzum Auswahlen einerdermeh- 
reren eindeutigen Nachrichten, die im Speicher 
gespeichert sind, auf der Grundlage des aktu- 
ellen Wertes des einen Parameters oder der 
mehreren Parameter; und 
eine Einrichtungzum Senden der ausgewahlten 
eindeutigen Nachricht an den Benutzer, um dem 
Benutzer anzuzeigen, dass der Client (1 10) mit 
dem Host(1 12) interagiert hat und dass der Host 
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(1 1 2) ein authentischer Host ist. 

5. Client (1 1 0) nach Anspruch 4, wobei die Einrichtung 
zum Interagieren mit dem Host (112) umfasst: 

5 

eine Einrichtung zum Senden einer Aufforde- 
rung an den Host (1 12); 

eine Einrichtung zum Empfangen einer Antwort 
auf die Aufforderung vom Host (1 1 2); und 
eine Einrichtung, um auf der Grundlage der Ant- 10 
wort zu bestimmen, ob der Host (112) ein au- 
thentischer Host (1 1 2) ist. 

6. Verfahren, dassvon einem Host (1 12) implementiert 
wird, um einem Benutzer zu ermoglichen, zu uber- 15 
prufen, dass der Host (1 12) ein authentischer Host 

(1 12) ist, umfassend: 

Empfangen eines Satzes von Benutzeridentifi- 
kationsinformationen vom Benutzer; 20 
Abrufen einer dem Benutzer zugeordneten ein- 
deutigen Nachricht auf der Grundlage der 
Benutzeridentifi kationsinformationen, wobei die 
eindeutige Nachricht eine geheime Nachricht 
ist, die nur ein authentischer Host (1 1 2) kennen 25 
wurde; und 

Senden der eindeutigen Nachricht an den Be- 
nutzer, um dem Benutzer zu ermoglichen, zu 
uberprufen, dass der Host (112) ein authenti- 
scher Host (1 12) ist, wobei die eindeutige Nach- 30 
richt eine geheime Nachricht ist, die dem Host 
(112) vom Benutzer im Voraus zur Verfugung 
gestellt worden ist; 

dadurch gekennzeichnet, dass der Schritt des 35 
Sendens einer eindeutigen Nachricht umfasst: 

Bestimmen des aktuellen Wertes eines Para- 
meters oder mehrerer Parameter; 
Auswahlen einer von mehreren eindeutigen 40 
Nachrichten auf der Grundlage des aktuellen 
Wertes des einen Parameters oder der mehre- 
ren Parameter; und 

Senden der ausgewahlten eindeutigen Nach- 
richt an den Benutzer, um dem Benutzer anzu- 45 
zeigen, dass der Client (1 10) mit dem Host(1 12) 
interagiert hat und dass der Host (112) ein au- 
thentischer Host (1 1 2) ist. 

7. Verfahren nach Anspruch 6, ferner umfassend: 50 

Empfangen eines Satzes von benutzerprivile- 
gierten Informationen vom Benutzer, wobei der 
Benutzer die benutzerprivilegierten Informatio- 
nen nur bereitstellt, nachdem der Benutzer 55 
uberpruft hat, dass der Host (1 12) ein authenti- 
scher Host (1 1 2) ist; und 
Bestimmen auf der Grundlage der benutzerpri- 



vilegierten Informationen, ob der Benutzer ein 
authentischer Benutzer ist. 

8. Host (112), der einem Benutzer ermoglicht, die Au- 
thentizitat des Hosts (112) zu uberprufen, umfas- 
send: 

einen Speicher zum Speichern einer eindeuti- 
gen Nachricht, die dem Benutzerzugeordnetist; 
eine Einrichtung zum Empfangen eines Satzes 
von Benutzeridentifikationsinformationen vom 
Benutzer; 

eine Einrichtung zum Abrufen der dem Benutzer 
zugeordneten eindeutigen Nachricht auf der 
Grundlage der Benutzeridentifikationsinforma- 
tionen, wobei die eindeutige Nachricht eine ge- 
heime Nachricht ist, die nur ein authentischer 
Host (1 1 2) kennen wurde; und 
eine Einrichtung zum Senden der eindeutigen 
Nachricht an den Benutzer, um dem Benutzer 
zu ermoglichen, zu uberprufen, dass der Host 
(1 1 2) ein authentischer Host (1 1 2) ist, wobei die 
eindeutige Nachricht eine geheime Nachricht 
ist, die dem Host (1 12) im Voraus vom Benutzer 
zur Verfugung gestellt worden ist; 

dadurch gekennzeichnet, dass der Speicher men- 
re re eindeutige Nachrichten speichert, wobei die 
Einrichtung zum Senden umfasst: 

eine Einrichtung zum Bestimmen des aktuellen 
Wertes eines Parameters oder mehrerer Para- 
meter; 

eine Einrichtung zum Auswahlen einerdermeh- 
reren eindeutigen Nachrichten, die im Speicher 
gespeichert sind, auf der Grundlage des aktu- 
ellen Wertes des einen Parameters oder der 
mehreren Parameter; und 
eine Einrichtungzum Senden der ausgewahlten 
eindeutigen Nachricht an den Benutzer, um dem 
Benutzer anzuzeigen, dass der Client (1 10) mit 
dem Host(1 12) interagiert hat und dass der Host 
(112) ein authentischer Host ist. 

9. Host (1 1 2) nach Anspruch 8, ferner umfassend: 

eine Einrichtung zum Empfangen eines Satzes 
von benutzerprivilegierten Informationen vom 
Benutzer, wobei der Benutzer die benutzerpri- 
vilegierten Informationen nur eingibt, nachdem 
der Benutzer uberpruft hat, dass der Host (1 12) 
ein authentischer Host (112) ist; und 
eine Einrichtungzum Bestimmen auf der Grund- 
lage der benutzerprivilegierten Informationen, 
ob der Benutzer ein authentischer Benutzer ist. 
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Revendi cations 

1 . Procede mis en oeuvre par un client (1 1 0) destine a 
autoriser un utilisateur a authentifier un note (1 12), 
comprenant : 

I'interaction (208) avec I'hote (1 12) pour deter- 
miner si I'hote (1 1 2) est ou non un note authen- 
tique (112) ; et 

en reponse a la determination du fait que I'hote 
(112) est un note authentique (112), I'envoi 
(220) d'un message unique qui signifie a I'utili- 
sateur que le client (110) a interagi avec I'hote 
(1 1 2) et que I'hote (1 1 2) est un note authentique 
(112), dans lequel le message unique est un 
message secret qui n'est pas connu de I'hote 
(112) et qui a ete fourni auparavant au client 
(1 1 0) par I'utilisateur ; 

caracteriseen ce que I'etape d'envoi d'un message 
unique comprend : 

la determination de la valeur courante d'un ou 
plusieurs parametres ; 

le choix, base sur la valeur courante des un ou 
plusieurs parametres, de Tun parmi une pluralite 
de messages uniques ; et 
I'envoi du message unique choisi a I'utilisateur 
pour signifier a I'utilisateur que le client (1 1 0) a 
interagi avec I'hote (1 12) et que I'hote (1 12) est 
un note authentique (112). 

2. Procede selon la revendication 1, dans lequel le 
message unique est envoye a I'hote (112) en vue 
d'un affichage par I'hote (112) a I'intention de I'utili- 
sateur. 

3. Procede selon la revendication 1 , dans lequel I'inte- 
raction avec I'hote (1 12) comprend : 

I'envoi a I'hote (1 12) d'une interpellation ; 

la reception depuis I'hote (1 12) d'une reponse 

a Interpellation ; et 

la determination, basee sur la reponse, du fait 
que I'hote (112) est ou non un note authentique 
(112). 

4. Client (110) destine a interagi r avec un note (112), 
le client (1 10) autorisant un utilisateur a authentifier 
I'hote (1 1 2), le client (110) comprenant : 

une memoire destinee a stocker un message 
unique ; 

un mecanisme destine a interagir avec I'hote 
pour determiner si I'hote (112) est ou non un 
note authentique ; et 

un mecanisme destine a envoyer, en reponse a 
une determination du fait que I'hote (1 1 2) est un 



note authentique (112), le message unique a 
I'utilisateur pour signifier a I'utilisateur que le 
client (110) a interagi avec I'hote (112) et que 
I'hote (112) est un note authentique, dans lequel 
5 le message unique est un message secret qui 

n'est pas connu de I'hote (1 12) et qui a ete fourni 
auparavant au client (1 10) par I'utilisateur ; 

caracterise en ce que la memoire stocke une plu- 
10 ralite de messages uniques, et dans lequel le meca- 
nisme pour I'envoi comprend : 

un mecanisme destine a determiner la valeur 
courante d'un ou plusieurs parametres ; 

15 un mecanisme destine a choisir, sur la base de 

la valeur courante des un ou plusieurs parame- 
tres, un message parmi la pluralite de messages 
uniques stockes dans la memoire ; et 
un mecanisme destine a envoyer le message 

20 unique choisi a I'utilisateur pour signifier a I'uti- 

lisateur que le client (1 1 0) a interagi avec I'hote 
(1 1 2) etque I'hote (1 12) estun note authentique. 

5. Client (1 10) selon la revendication 4, dans lequel le 
25 mecanisme destine a interaction avec I'hote (1 12) 

comprend : 

un mecanisme destine a envoyer une interpel- 
lation a I'hote (112) ; 
30 un mecanisme destine a recevoir depuis I'hote 

(112) une reponse a interpellation ; et 
un mecanisme destine a determiner sur la base 
de la reponse si I'hote (112) est ou non un note 
authentique (112). 

35 

6. Procede mis en oeuvre par un note (1 1 2) pour auto- 
riser un utilisateur a verifier que I'hote (1 12) est un 
note authentique (1 12), comprenant : 

40 la reception d'un ensemble d'informations 

d'identification utilisateur depuis I'utilisateur ; 
la recuperation, sur la base des informations 
d'identification utilisateur, d'un message unique 
associe a I'utilisateur, le message unique etant 

45 un message secretqueseul un note authentique 

(112) connaTtra ; et 

I'envoi du message unique a I'utilisateur pour 
autoriser I'utilisateur a verifier que I'hote (1 12) 
est un note authentique (112), dans lequel le 
50 message unique est un message secret fourni 

auparavant a I'hote (1 1 2) par I'utilisateur ; 

caracterise ce que I'etape d'envoi d'un message 
unique comprend : 

55 

la determination de la valeur courante d'un ou 
plusieurs parametres ; 

le choix, sur la base de la valeur courante des 
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un ou plusieurs parametres, d'un message par- 
mi une pluralite de messages uniques ; et 
renvoi du message unique choisi a I'utilisateur 
pour signifier a I'utilisateur que le client (1 1 0) a 
interagi avec I'hote (1 12) et que I'hote (1 12) est 5 
un note authentique (112). 

7. Procede selon la revendication 6 comprenant de 
plus : 

10 

la reception d'un ensemble d'informations privi- 
legiees utilisateur depuis I'utilisateur, I'utilisa- 
teurfournissant les informations privilegiees uti- 
lisateur seulement apres que I'utilisateur a veri- 
fie que I'hote (112) est un hote authentique 15 
(112) ;et 

la determination, sur la base des informations 
privilegiees utilisateur, dufaitque I'utilisateur est 
ou non un utilisateur authentique. 

20 

8. Hote (112) qui autorise un utilisateur a verifier 
I'authenticite de I'hote (1 12), comprenant : 

une memoire destinee a stocker un message 
unique associe a I'utilisateur ; 25 
un mecanisme destine a recevoir depuis I'utili- 
sateur un ensemble d'informations d'identifica- 
tion utilisateur ; 

un mecanisme destine a recuperer, sur la base 
des informations d'identification utilisateur, le 30 
message unique associe a I'utilisateur, le mes- 
sage unique etant un message secret que seul 
un hote authentique (112) connattra ; et 
un mecanisme destine a envoyer le message 
unique a I'utilisateur pour autoriser I'utilisateur 35 
a verifier que I'hote (1 12) est un hote authenti- 
que (112), dans lequel le message unique est 
un message secret fourni auparavant a I'hote 
(1 1 2) par I'utilisateur ; 

40 

caracterise en ce que la memoire stocke une plu- 
rality de messages uniques, etdans lequel le meca- 
nisme pour I'envoi comprend : 

un mecanisme destine a determiner la valeur 45 
courante d'un ou plusieurs parametres ; 
un mecanisme destine a choisir, sur la base de 
la valeur courante des un ou plusieurs parame- 
tres, un message parmi la pluralite de messages 
uniques stockes dans la memoire ; et 50 
un mecanisme destine a envoyer le message 
unique choisi a I'utilisateur pour signifier a I'uti- 
lisateur que le client (1 1 0) a interagi avec I'hote 
(1 1 2) etque I'hote (1 12) estun hote authentique. 

55 

9. Hote (1 12) selon la revendication 8 comprenant de 
plus : 



un mecanisme destine a recevoir depuis I'utili- 
sateur un ensemble d'informations privilegiees 
utilisateur, I'utilisateur entrant les informations 
privilegiees utilisateurseulement apres que I'uti- 
lisateur a verifie que I'hote (112) est un hote 
authentique (112) ; et 

un mecanisme destine a determiner, sur la base 
de des informations privilegiees utilisateur, si 
I'utilisateur est ou non un utilisateur authentique 
(112). 
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USER INITIATES 
INTERACTION BETWEEN 

THE CLIENT AND 
THE HOST 



CLIENT INTERACTS 
WITH THE HOST TO 
DETERMINE WHETHER 
THE HOST IS AN 
AUTHENTIC HOST 



/-204 



/•208 



NO 



IS 

THE HOST 

AUTHENTIC 

? 



•212 



CLIENT STOPS 
ALL FURTHER 
INTERACTION 
WITH THE HOST 



216 



YES 



CLIENT SENDS UNIQUE 
MESSAGE(S) TO THE USER 



y-220 



USER REVIEWS 
MESSAGE(S) 



y-224 




232 



USER PROVIDES 
USER-PRIVILEGED 
INFORMATION TO 
THE HOST 



USER STOPS 
ALL FURTHER 
INTERACTION 
WITH THE HOST 

^236 
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HOST SENDS A PROMPT TO 
THE USER FOR SOME USER 
IDENTIFICATION INFORMATION 



404 



USER PROVIDES USER 
IDENTIFICATION TO THE HOST 



I 



408 



HOST RETRIEVES UNIQUE MESSAGE 
ASSOCIATED WITH THE USER 



I 
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HOST SENDS UNIQUE MESSAGE TO 
THE USER ALONG WITH A PROMPT 
FOR USER-PRIVILEGED INFORMATION 



416 



420 




428 



USER PROVIDES 
USER-PRIVILEGED 
INFORMATION 
TO THE HOST 



USER STOPS 
ALL FURTHER 
INTERACTION 
WITH THE HOST 

432 



HOST VERIFIES USER 
PRIVILEGED INFORMATION 



s 



436 



16 



EP 1 046 976 B1 




17 



